A Software-Configuration-Management (SCM) system is used to manage the development of configurations of a software system. When a software system is being developed in an SCM repository, the historical sequence of configurations of that software system is called a “stream”. When a developer wants to create a new configuration of that software system, the developer “accepts” the latest configuration from the stream for that software system into a “workspace”. The developer then makes changes to the configuration in the workspace, and when the developer has created the desired new configuration in the workspace, the developer “delivers” the configuration in the workspace to the stream, which adds that configuration to the end of the stream, making it the latest configuration of that stream.
In order to avoid over-writing configurations created by other developers, before a developer can deliver to the stream, the developer must first accept into the workspace the latest configuration of the stream. If the latest configuration contains changes to the same files or directories that the developer has changed, this results in “merge conflicts” for those files or directories in the workspace. These conflicts must be resolved by the developer (via automatic or manual merge tools) before the configuration of the workspace can be delivered to the stream.
It is common for multiple SCM repositories to be in use in a single organization. In some cases, this is because no one SCM repository has all the features needed by the organization. In other cases, this is because it takes a long time to transition all of the business processes and projects from one SCM repository to another, and so both SCM repositories remain in use for an extensive period of time. When a common software component is shared by software systems that are being developed with different SCM repositories, some mechanism must be provided to allow developers of those software systems to develop and share new configurations of the common software component.
A common approach to this problem is to have the developers learn how to load configurations of the shared components from their respective SCM repositories into a common file system, and then to use the build system to integrate the files from the different SCM repositories.
But there are several important problems with this approach. In particular, a software project wants to record the configuration of all components needed for a particular configuration of the software system, which would require recording relationships between different SCM repositories. In addition, a developer will often need to make changes to the shared component, but interactions with an SCM system to make changes to a configuration can be very complex (especially to reconcile and merge parallel changes), so attempting to do so with multiple SCM repositories can be very confusing and result in significant errors.